The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Simple Network Time Protocol (SNTP), as described in Request for Comments (RFC) 2030 of the Internet Engineering Task Force, may be used for synchronizing clocks of network devices within a tolerable range of time. In SNTP and other prior methods, clock synchronization in a network depends upon a centralized server, or a coordinating set of servers from which systems can acquire the same master or “wall clock” time. The primary use of SNTP is to synchronize clocks using timestamps sent between servers and clients.
The Kerberos protocol of RFC 1510 uses timestamps to declare freshness of a Kerberos “ticket” that is included in a packet. However, the Kerberos timestamp is not used for synchronization between a sender and receiver.
The Intelligent Secure-Internet Server (IS-IS) routing protocol self-synchronizes Link State Packets (LSPs) comprising Protocol Data Units (PDUs) in a network using sequence numbers rather than timestamps. In IS-IS, the sequence number is associated with a particular LSP. Receiving an LSP with a higher sequence number from a neighbor indicates a more recent version of the LSP. Receiving an LSP with a lower sequence number from a neighbor causes a router to respond with its more recent version of the LSP.
Each of these approaches has disadvantages. For example, SNTP and other time synchronization mechanisms are difficult to use when groups contain a large number of members, and/or the group members are distributed over a wide area. Additionally, there are many networking scenarios where time services are not available, or are not supported by the devices performing authentication services.
In a data encryption protocol, such as Internet Protocol Security (EPSec) as described in RFC 2401 and other RFCs, often a receiver will accept a valid packet sent by a sender no more than once. Accepting a valid packet only once facilitates the detection and defeat of packets that are intentionally replayed by an adversary, as well the detection and discarding of packets that are accidentally duplicated in the network. If a receiver does not detect replayed packets, an attacker can use the replayed packet to cause the receiver to accept stale data as if it were fresh data. If the information in the packet is time sensitive, such a replay could be disastrous.
Furthermore, processing replayed packets wastes resources. Replayed packets can cause a cryptographic endpoint to unnecessarily expend CPU or memory resources, which an attacker may use for malicious purposes. For example, replayed packets can be used in Denial of Service (DoS) attacks as well as attacks seeking to fool the receiver.
Problems associated with mistaking stale data for fresh data, and the waste of resources that can be caused by replaying packets, are greatly magnified when packets are sent to a group. For example, an IP multicast group with 1000 receivers could be a particularly attractive target for an attacker, since the replay of a single stream of multicast packets will affect all 1000 receivers. If stale data is replayed, the entire group is fooled into accepting incorrect information thereby providing an advantage to the attacker. In the cases of a DoS attack, the entire group of receivers may be disabled due to resource exhaustion. Similarly, accidentally replayed multicast packets also provide incorrect data to all receivers or strain resources.
IPSec includes protocols for securing packet flows, and protocols for exchanging encryption keys used for setting up the secure flows. One IPSec protocol for securing packet flows is Encapsulating Security Payload (ESP), as described in RFC 2406, which encrypts packet flows. The IPSec Authentication Header (AH) of RFC 2402 provides authentication and message integrity guarantees for packet flows (but does not offer confidentiality).
The ESP and AH protocols provide replay protection to detect duplicate packets between two systems. However, the replay protection was designed for pair-wise communications between exactly two systems. When IPSec is used to protect multi-sender group traffic, replay protection becomes problematic. ESP and AH make provisions for replay protection through the use of sequence numbers. However, when IPSec is applied to group traffic with more than one sender, multiple senders may use the same sequence number. Consequently, IPSec sequence numbers are ineffective for preventing replay, because the uniqueness property of sequence numbers is violated, and therefore receiving two packets having the same sequence number does not indicate replay.